The present invention relates generally to computer systems and to computerized document processing systems. More particularly, the present invention relates to apparatuses and methods for processing a compound document in a computer.
Traditionally, documents are processed using stand-alone application programs. Each document in the application-centered approach typically utilizes a single application program to render and manipulate its data. Further, data within an application-centered document is homogenous throughout. By way of example, a text document typically contains only text and is rendered and manipulated by a word processor application program. In the application-centered world, if a computer user wants to create a graphics image, he or she would typically have to switch to a different document that is associated with, say a graphics application program.
In contrast documents are documents whose contents are non-homogenous. A compound document may have within it different types of data, such as text, graphics, sound, or other types of data that are displayable or manipulable using a computer. Representative existing compound document architectures include OpenDoc.TM. by Apple Computer, Inc. of Cupertino, Calif. and OLE.TM. by Microsoft Corporation of Redmond, Wash.
Furthermore, a compound document embeds, or incorporates, multiple applications in a single compound document framework. Each application program so embedded is responsible for rendering and manipulating its associated data in a discrete content area of the compound document. As such, a computer user may move among the discrete content areas to use the respectively associated embedded applications to edit the compound document's non-homogeneous contents without having to switch documents. For this reason, many people find that compound documents are easy to work with.
To facilitate a discussion of compound documents, FIG. 1 shows a traditional compound document along with its various constituting elements. The compound document of FIG. 1 may be created by, for example, the aforementioned OpenDoc.TM. compound document software. Referring now to FIG. 1, there is shown a window 200 representing a window within which a compound document may be displayed and manipulated. As is well known to those of skill in the art, window 200 may include a menu bar 202 and a display area 204. There may optionally be provided a scroll bar 206 for permitting the computer user to scroll through different portions of the compound document.
Within display area 204 there is shown a root view of the compound document. In a compound document, the aforementioned different types of data, e.g., text, graphics, sound, and the like, co-exist within a document "container." The root view is a visual representation of these different types of data in the aforementioned compound document container.
Within the document container, a plurality of objects may be embedded, i.e., incorporated or contained. As the term is used herein, an object is defined as an area in a document that contains information or "content." Programs that manipulate object information are called object editors. Visual representations of objects on screen or in an electronic document are called data objects. In a typical compound document architecture objects may contain other objects in an embedding hierarchy, where the first object present in a document is referred to as the root object. Since the root object is an embedded object, it delineates the content area within which an intrinsic text content associated with the root object is rendered. An example of the intrinsic text content associated with the root object is illustrated in the sentence that reads: "This is a South American iguana."
To render and manipulate this intrinsic text content of the root object, there is associated with the root object a root object editor, also known as a root editing component, representing the underlying program that manipulates object content. In the example of FIG. 1, this root object editor is shown as object editor 214 and may be implemented by, for example, a word processor.
Besides the root object, the document container is further capable of embedding, i.e., incorporating, other objects. Each embedded object, whether or not a root object, delineates a discrete, mutually exclusive content area within the compound document. Content areas are mutually exclusive because each content area only contains one type of data. By way of example, there is shown in FIG. 1 an embedded object 208, which serves to delineate the content area of the compound document that is associated with a graphic image 210. Note that only graphics data is shown in the content area associated with embedded object 208. In contrast with the root object, which represents the first level of embedding in the document container, embedded object 208 represents a deeper level of embedding.
Each embedded object has associated with it an object editor, which is used for rendering and manipulating the content that is intrinsic to that embedded object. An example of an object editor, i.e., root object editor 214, has already been discussed in connection with the embedded root object. As a further example, object editor 216 of FIG. 1 may represent the graphics object editor associated with embedded object 208 for rendering and manipulating graphics image 210 within object 208. Object editor 216 may represent, for example, a simple drawing program.
In general, each object editor has a proprietary user interface, which is typically furnished by the developer of the application program code underlying that embedded object editor. The user interface represents, among other things, the overall "look" of the content area with which an object editor is associated, the manner in which the content is rendered, as well as the manner in which editing tools are implemented. The portion of the user interface for laying out the editing tools is referred to herein as a UI container since its role, be it a menu bar, a floating palette, a dialog box, or the like, is to provide an environment for implementing editing tools.
Within object 208 of FIG. 1, there is further embedded an object 212, representing a yet further level of embedding within the document container. Embedded object 208 serves to delineate the content area associated with the text content inside it. This text content is represented by, for example, the sentence in FIG. 1 that reads: "This is a text part." Embedded object 212 has associated with it object editor 218, which is used for rendering and manipulating the text content within embedded object 212. As is apparent in the relationship between the document container, the root object, object 208, and object 212, there could be multiple levels of embedding and deeply nested contents within a compound document.
It is typically not required for object editor 218 to be the same as object editor 214, i.e., it is not required that these two object editors utilize the same underlying program. By way of example, object editor 214 may represent one particular text editing program while object editor 218 may represent another text editing program. However, it is entirely permissible for both object editors 214 and 218 to be the same application program if such is desired by the computer user. For example, object editor 214 and object editor 218 may both implement the same word processor in different embedded objects. In this case, the object editor associated with the root view as well as embedded object 212 may both have pointers to the underlying application program, thereby enabling one application program to serve both of these embedded objects.
In the compound document architecture, the data representing the text content within the root view of display area 204, the graphics content within object 208, and the text content within object 212 may be stored within a single file object 220, which exists inside the computer's persistent storage system. For example, each of object editors 214, 216, and 218 may respectively store their associated data inside a respective section of file object 220. As the document is read from storage, the data of each section may be recalled from file object 220 and rendered in the compound document within window 200 by the object editor with which the stored data in each section is associated.
If an object editor is not available for recalling and rendering/manipulating the data stored in a section of file object 220, that data is simply not displayed and is not manipulable in the compound document. However that data still resides with the document and is not destroyed or corrupted. By way of example, this situation may occur when a document, which has been created on a first computer, is moved to a second computer which lacks the appropriate object editor to recall and render some of the data. When the compound document is activated by the second computer, the embedded object that delineates the content area associated with the missing object editor may still appear. However, the content inside that object is likely a static image. In some case, the static image may simply be a gray background.
Although the non-homogenous contents of a typical compound document may appear visually seamless, the typical compound document is in fact more like a collage of embedded objects, wherein each embedded object editor is in effect a separate application program within a document framework. The disjointed nature of the typical compound document is most clearly felt during an editing session. For example, when computer users move their selection from one content area of a typical compound document to another content area, say to manipulate different pieces of data, the effect may be similar to that observed when Computer users switch among stand-alone applications in the application-centered approach in that the user interface changes. This is because in a compound document, an object editor does not operate in the content area with which it is not associated. For example, object editor 214, representing the text object editor for the intrinsic text content in the root object, typically does not get involved in rendering or manipulating the graphics images within object 208.
When a user changes object editors to manipulate different pieces of data, the user interface of the typical compound document may change completely and suddenly. This is because each object editor in the typical compound document implements its own user interface and furnishes its own set of tools with which its associated content is rendered and manipulated.
By way of example, if object editor 218 has a different user interface from that of object editor 216, the user interface will change when the computer user moves from editing the text content in embedded object 212 to editing graphics image 210 in embedded object 208. When the user interface changes, the old UI container and its editing tools are immediately replaced with a new UI container and new editing tools for editing the newly selected content. In some cases, the changes may occur suddenly and disorientingly. By way of example, sudden changes to the appearance of the traditional compound document may occur when the computer user moves from one object editor, say one having a UI container that lays out its editing tools in a red floating palette, to an object editor that lays out its editing tools in a blue menu bar.
Further, the fact that an object editor, its editing tools, and its UI container are interdependent on one another in a typical compound document also presents other problems. For one, this fact adversely impacts modularity of design and makes global changes difficult to implement. Consider the situation where a computer user wishes to globally change the pen width of all drawing tools in a compound document that employs, say five different graphics object editors. It is not possible to effect such global changes in one operation in the traditional compound document architecture since each object editor exclusively "owns" its editing tools. Therefore, the computer user must change the pen width tool provided with each object editor, i.e., make five changes, in order to accomplish this task.
Consequently, what is needed is an improved method and apparatus for processing a compound document. The improved method and apparatus preferably permit a set of editing tools to work with object editors throughout a compound document and vice versa. Further, it is preferable that the improved method and apparatus provide a substantially consistent user interface during a compound document editing session irrespective of which object editor is currently active.